На днях на сайте проекта VMware Labs появилась очередная новая штука - средство Infrastructure Deployer for vCloud NFV, позволяющее в автоматическом режиме развернуть платформу VMware vCloud NFV (в издании NFV 3.2 VCD) и сконфигурировать ее. Напомним, что NFV - это комплексное решение по виртуализации сетевого стека для сервис-провайдеров (грубо говоря, замена аппаратных роутеров, сетевых экранов и прочих компонентов комплексом из виртуальных машин, предоставляющих динамические сетевые сервисы).

Сам рабочий процесс развертывания основан на архитектуре VMware vCloud NFV 3.0 Reference Architecture и предназначен только для инфраструктуры, развертываемой с нуля (то есть донастроить существующие компоненты не получится).

Сам продукт состоит из двух компонентов:

• Входной текстовый файл, в который нужно поместить данные об окружении и компонентах платформы vCloud NFV, которые необходимо развернуть.
• Скрипты PowerShell, которые будут исполнены в процессе развертывания.

Для запуска процедуры автоматизированного развертывания потребуется выполнение следующих условий:

• Работающий DNS-сервер.
• Все компоненты должны иметь актуальные FQDN в DNS.
• В инфраструктуре должен функционировать NTP-сервис.
• PowerShell не ниже 5.0 и PowerCLI не ниже 10.x.
• На Jump VM (там, где запускаются скрипты) должны быть установлены все последние обновления Windows.

Скачать Infrastructure Deployer for vCloud NFV можно по этой ссылке. Там же доступно развернутое руководство пользователя на 57 страницах.

Год назад мы писали о средствах VMware vCenter Server Appliance для резервного копирования и восстановления на уровне файлов. Эти функции появились в VMware vCSA 6.5 и были существенно доработаны в версии vCSA 6.7 (отдельный раздел Backup, запланированные резервные копии, политика хранения бэкапов, браузер файлов и т.п.).

В то же время, у пользователей VMware vCSA есть запрос на автоматизацию процесса резервного копирования средствами PowerCLI через механизм vSphere RESTful API. На блогах VMware появилась интересная статья, описывающая данный процесс, приведем ниже основные его моменты.

Взаимодействие с механизмом резервного копирования vCSA происходит через модуль CIS, который взаимодействует с компонентами инфраструктуры на низком уровне. Первым шагом как раз и является подключение к службе CIS:

Connect-CisServer -Server vcsa01.corp.local

Затем нужно найти сервис, для которого нужно сделать резервную копию:

Get-CisService -Name *backup*

Из вывода видно, что нам нужен сервис com.vmware.appliance.recovery.backup.job. Сохраняем его в переменую и передаем в Get-Member:

В выводе мы видим метод create, который позволяет создать задачу резервного копирования, а также свойство help, которое помогает сформировать входные параметры для задачи РК:

$backupJobSvc.Help.create.piece

Теперь можно заполнить поля задачи данными из нашего окружения. Параметр parts ожидает на вход тип массив, также в параметре password нужно передать специальный тип, чтобы он был принят:

$backupSpec.parts = @("common")

$backupSpec.location_type = "FTP"

$backupSpec.location = "ftp01.corp.local"

$backupSpec.location_user = "backup"

[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

$backupSpec.comment = "PowerCLI Backup Job"

После этого можно уже создавать задачу РК:

$backupJob = $backupJobSvc.create($backupSpec)

Теперь объединяем это все в один скрипт:

# Login to the CIS Service of the desired VCSA

Connect-CisServer -Server vcsa01.corp.local
# Store the Backup Job Service into a variable

  $backupJobSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.job
# Create a specification based on the Help response

  $backupSpec = $backupJobSvc.Help.create.piece.CreateExample()
# Fill in each input parameter, as needed

  $backupSpec.parts = @("common")

  $backupSpec.location_type = "FTP"

  $backupSpec.location = "ftp01.corp.local"

  $backupSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

  $backupSpec.comment = "PowerCLI Backup Job"
# Create the backup job 

  $backupJobSvc.create($backupSpec)

Чтобы создать запланированную задачу резервного копирования, надо использовать сервис com.vmware.appliance.recovery.backup.schedules. Тут нам надо задать schedule ID (это строковый параметр по вашему выбору, задается опционально) и заполнить спецификацию аналогично предыдущему сценарию.

Периодичность бэкапа задается через свойство days, которое можно оставить неустановленным (бэкап будет делаться каждый день), либо задать конкретные дни в виде массива.

Ну и, собственно сам сценарий запланированного бэкапа VMware vCSA на уровне файлов через PowerCLI:

# Store the Backup Job Service into a variable

$backupSchedSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.schedules
# Create a Schedule ID specification based on the Help response

  $schedSpec = $backupSchedSvc.Help.create.schedule.Create()

  $schedSpec = 'weekly'
# Create a specification based on the Help response

  $backupSchedSpec = $backupSchedSvc.Help.create.spec.Create()

  $backupSchedSpec.parts = @("common")

  $backupSchedSpec.location = "ftp://ftp01.corp.local"

  $backupSchedSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSchedSpec.location_password = "VMware1!"

  $backupSchedSpec.enable = $true

  $recurSpec = $backupSchedSvc.Help.create.spec.recurrence_info.Create()

  $recurSpec.days = @("Sunday")

  $recurSpec.minute = '59'

  $recurSpec.hour = '23'

  $backupSchedSpec.recurrence_info = $recurSpec

  $retentSpec = $backupschedsvc.help.create.spec.retention_info.Create()

  $retentSpec.max_count = '5'

  $backupSchedSpec.retention_info = $retentSpec
# Create the backup job 

  $backupSchedSvc.create($schedSpec, $backupSchedSpec)
 

Это все соответствует запланированной задаче РК со следующими параметрами:

Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.

На днях компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 11.5. Напомним, что о прошлой версии, PowerCLI 11.4, мы писали в конце августа этого года.

Давайте посмотрим, что интересного появилось в PowerCLI 11.5:

1. Новые командлеты для управления библиотеками Content Library.

В последних версиях VMware vSphere функциональность библиотек Content Library была существенно доработана (кстати, это был один из первых сервисов, использовавших vSphere Automation REST API). PowerCLI старается не отставать, поэтому тут было добавлено 8 новых командлетов, а также была добавлена поддержка шаблонов (templates):

• New-ContentLibraryItem
• Set-ContentLibraryItem
• Remove-ContentLibraryItem
• Export-ContentLibraryItem
• New-ContentLibrary
• Set-ContentLibrary
• Get-ContentLibrary
• Remove-ContentLibrary

Вот пример опроса содержимого объекта библиотеки:

2. Обновление механизма vCenter Alarm Management.

В PowerCLI уже имеются средства для управления алармами vCenter, но их пользователям явно недостаточно. Новая версия PowerCLI имеет 6 новых и 3 обновленных командлета для управления определениями алармов, триггерами, а также для получения данных о типах событий и метриках.

Новые командлеты:

• New-AlarmDefinition
• Remove-AlarmDefinition
• New-AlarmTrigger
• Get-AlarmTrigger
• Get-EventType
• Get-Metric

Обновленные командлеты:

• New-AlarmAction
• New-AlarmActionTrigger
• Set-AlarmDefinition

Вот пример работы нового командлета, где создается определение аларма в vCenter:

3. Обновление модуля VMware Cloud on AWS.

Модуль для управления VMware Cloud on AWS (VMC) - это один из самых новых модулей. Ранее он использовался как средство низкоуровневого взаимодействия с инфраструктурой VMC. Теперь же этот низкоуровневый интерфейс был заменен на высокоуровневые команды для осуществления операций, необходимых пользователю.

Пример - теперь для создания объекта SDDC используется 1 команда вместо 20 строчек кода, которые требовались раньше:

А вот, собственно, новые командлеты, которые появились для VMC (подробнее - здесь):

• Get-VmcSddc
• Set-VmcSddc
• New-VmcSddc
• Remove-VmcSddc
• Add-VmcSddcHost
• Remove-VmcSddcHost
• Get-AwsAccount
• Get-AwsVpcSubnet

4. Обновленный модуль VMware Core.

Здесь, прежде всего, была доработана функциональность, связанная с тэгами. Командлет Get-Tag и параметр Tag для Get-VM были обновлены, также были обновлены и командлеты Get/Remove-TagAssignment.

Кроме того, базовые функции обогатились некоторыми полезными функциями. Например, теперь при создании виртуальной машины из шаблона средствами командлета New-VM появилась возможность настройки портгруппы через параметры NetworkName или Portgroup.

Также в vSphere 6.7 появилось новое свойство виртуальной машины CreateDate, которое теперь также поддерживается в командлетах, связанных с виртуальной машиной:

Больше информации о новых возможностях VMware PowerCLI 11.5 можно почерпнуть в следующих документах:

• VMware PowerCLI Change Log
• VMware PowerCLI 11.5.0 User’s Guide
• VMware PowerCLI 11.5.0 Cmdlet Reference

Update-Module -Name VMware.PowerCLI

Скачать VMware PowerCLI 11.5 можно по этой ссылке.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предлагающего услугу аренды виртуальных машин из облака. Делать бэкапы любят не все. Однако лучше потратить пять минут на бэкап, чем столкнуться с отсутствием возможности восстановления после сбоя. В Veeam это хорошо понимают, поэтому в Availability Suite...

На сайте проекта VMware Labs очередное обновление - вышла новая версия продукта Virtual Machine Compute Optimizer 2.0. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:

• Собираются приоритеты найденных несоответствий.
• Вывод деталей найденных несоответствий.
• Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
• В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
• Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
• В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
• Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.

Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.

На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

В версии vSAN Performance Monitor 1.2 появились следующие улучшения:

• Исправлена проблема с настройкой CA-сертификатов
• Некоторые доработки агента, собирающиего данные
• Убран анонимный сбор статистики от influxdb

Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.

Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.

В данном обновлении появились следующие новые функции:

• Добавлена конфигурация предпочитаемого HTTP-запроса
• Добавлена конфигурация маппинга критичности алерта
• Добавлены черные списки с полем resourceName
• Добавлена настройка структуры конечного устройства (endpoint) для обработки разного поведения на базе состояний сработавшего/несработавшего триггера
• Добавлено описание симптомов в одну строку как и для рекомендаций.
• Различные исправления ошибок

Обновленный vRealize Operations REST Notifications Helper 1.3 можно скачать по этой ссылке.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).

Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:

Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.

На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

На портале VMware Labs очередное обновление - вышла новая версия полезной утилиты VMware OS Optimization Tool, которая позволяет подготовить гостевые ОС к развертыванию и проводить тюнинг реестра в целях оптимизации производительности, а также отключение ненужных сервисов и запланированных задач.

Последний раз мы писали про эту утилиту в апреле прошлого года, давайте же посмотрим, что нового появилось в VMware OS Optimization Tool b1110:

• Новая кнопка Common Options - позволяет быстро выбрать и настроить параметры для управления общей функциональностью. Теперь в интерфейсе можно с помощью данного блока выбрать нужный вариант тюнинга, не заглядывая в различные индивидуальные настройки в разных разделах.
• Разделение Windows 10 на 2 шаблона, чтобы лучше обрабатывать различия между этими двумя версиями. Один шаблон для версий 1507-1803, а второй - для 1809-1909.
• Улучшенные оптимизации для Windows 10, особенно для версий 1809 - 1909.
• Исправлены многочисленные ошибки: сброс настроек при сохранении кастомизированных шаблонов, недоступные ссылки на вкладке Reference, недоступность Windows Store после оптимизации и многое другое.

Для новых версий Windows 10 была добавлена следующая функциональность для шаблонов:

• Перемещение элементов между mandatory user и current user к default user.
• Добавлено 34 новых элемента групповых политик, относящихся к OneDrive, Microsoft Edge, приватности, Windows Update, нотификациям и диагностике.
• Добавлено 6 элементов в группу Disable Services.
• Добавлен 1 элемент в группу Disable Scheduled Tasks.
• Добавлен 1 элемент в группу HKEY_USERS\temp настроек реестра.
• Добавлен 2 элемента в группу настроек HKLM.
• Упрощено удаление встроенных приложений Windows (кроме Windows Store).

Скачать VMware OS Optimization Tool b1110 можно по этой ссылке.

Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.

Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).

Главное в этой эволюции то, что такие вещи как RDMA стали вполне доступными по цене, а значит можно обсуждать новые архитектуры на их основе. Тем более, что одной из основных проблем текущих датацентров стала трудность масштабирования инфраструктуры по памяти - ведь когда на одном из хостов не влезают виртуальные машины по RAM (например, есть машины с очень большим потреблением памяти), нужно увеличивать память и на всех остальных хостах кластера.

Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.

Кстати, еще есть и ограничение по объему DRAM на одном хосте - как правило, это несколько ТБ. Как мы видим на картинке выше, эту проблему можно решить созданием отдельных Memory-серверов в кластере, которые могут раздавать свою память по высокопроизводительной шине RDMA.

Технологии сетевого доступа к памяти будут развиваться, и скоро возможность использования виртуальными машинами страниц памяти с Memory-хостов будет вполне реальна:

Для этого компания VMware разработала отдельный paging-механизм, который позволяет проводить паджинацию страниц на удаленный сервер вместо локального диска, для чего будет необходим локальный кэш. При запросе страницы с удаленного сервера она сначала будет помещаться в локальный кэш для ускорения повторного использования.

Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:

• Сбои, связанные с доступом к Cluster Memory
• Безопасность и сохранность данных
• Управление ресурсами в распределенной среде
• Увеличение потребления межсерверного канала
• Управление жизненным циклом страниц
• Производительность механизма в целом

В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.

Конечно же, самая интересная проблема - это производительность ВМ в таких условиях. VMware сделала некоторые тесты, где были использованы различные соотношения локальной и удаленной памяти. На получившемся графике видна производительность в числе выполненных операций в минуту:

Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.

Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.

Продолжаем рассказывать об анонсах продуктов и технологий, представленных на конференции VMworld 2019, так как есть о чем еще говорить. Одним из главных анонсов для сервис-провайдеров на мероприятии стала доступность платформы VMware Cloud Foundation for Cloud Providers.

Напомним, что vCloud Foundation (VCF) - это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Важно, что в рамках этой архитектуры полностью поддерживается взаимодействие всех компонентов друг с другом, поэтому для VCF есть список продуктов и их версий (и это могут быть не самые последние версии), который и составляет архитектуру VCF. Напомним, что о версии VCF 3.0 мы писали вот тут.

Представленная архитектура VCF для сервис-провайдеров (VCPP) позиционируется как главный продукт для построения выделенных облачных инфраструктур для крупных клиентов (Dedicated Private Clouds). Решение комбинирует в себе возможности платформ VMware Software-Defined (vSphere и прочие продукты) и решения для миграции в виртуальную среду HCX. Облачная платформа VCF поставляется в трех изданиях, в зависимости от изданий входящих в него продуктов (подробнее об этом тут):

VMware Cloud Foundation соединяет в себе портфолио SDDC (vSphere, NSX, vSAN), а также средства управления SDDC Manager, что позволяет создать валидированную архитектуру на стороне сервис-провайдера и обеспечить управление жизненным циклом всех компонентов, чтобы облачные провайдеры могли запускать апгрейд всей инфраструктуры в один клик.

Кстати, решение VCF можно потестировать вживую в рамках лабораторной работы Hands-on Lab.

Онбординг пользователей в облачную среду провайдеров VCPP помогает производить решение VMware HCX, которое обеспечивает процесс миграции физических ресурсов предприятия в облачную среду на базе виртуальных машин в облаке:

Надо сказать, что решение VCF может работать поверх гибридной инфраструктуры предприятия - просто в облаке сервис-провайдера появляется еще один объединяющий элемент. Для традиционных хостинг-провайдеров, которые предоставляют услуги Shared Hosting / Virtual Private Servers, решение VCF для VCPP позволит получить крупных заказчиков, при этом оно изначально заточено под выделенную инфраструктуру со множеством клиентов.

Для старта с решением VMware Cloud Foundation for Cloud Providers партнерам потребуется пройти специальное обучение в течение 1 недели.

Вторым важным анонсом стал выпуск архитектуры vCloud Foundation версии 3.8.1. Надо сказать, что этот релиз сфокусирован на инфраструктуре контейнеризованных приложений под управлением Kubernetes. Такая инфраструктура управляется совершенно иначе, по сравнению с традиционной платформой для виртуальных машин, поэтому целью было объединить рабочие процессы PKS (Pivotal Container Service) и VCF.

В этом релизе у VCF 3.8.1 появились следующие новые возможности:

• Автоматизация развертывания решения PKS - теперь можно автоматически разместить нагрузку VMware Enterprise PKS в домене рабочей нагрузки NSX-T.

Средства интеграции VCF и PKS построены таким образом, что администраторам облака не требуется никаких специальных знаний в области Kubernetes, чтобы управлять интегрированной инфраструктурой контейнеров и виртуальных машин. Подробнее об этом рассказано тут.

• Поддержка двухфакторной аутентификации - теперь она доступна для API на базе паролей в консоли SDDC Manager.
• Улучшенные возможности Phone Home - предоставляет возможность провайдеру организовать функции phone home для данных в SDDC Manager одним кликом.
• Обновленные списки версий ПО (Bill of materials, BOM) - включают в себя vSphere 6.7 Update 3, vSAN 6.7 U3, новые версии Horizon, NSX-T и vRealize.

• Улучшения безопасности и исправления ошибок.

Более подробно о новых возможностях VCF можно узнать из Release Notes.

Перед самой конференцией VMworld 2019, которая прошла на прошлой неделе в Сан-Франциско, компания VMware анонсировала полезный сервис ports.vmware.com, где любой желающий может вывести порты и соединения по различным протоколам для следующих продуктов серверной линейки:

• vSphere
• vSAN
• NSX for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation

Выглядит это вот таким образом (кликабельно):

Как мы видим, в левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов и характера взаимодействий. Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.

Результаты можно вывести в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке version указана версия продукта, для которой эта информация актуальна.

Если раньше всю эту информацию приходилось вылавливать из статей базы знаний VMware, а также подглядывать в различные постеры, то теперь все очень удобно организовано на одном экране (и что важно с возможностью поиска по результатам). Также есть удобная функция - сортировка по колонкам, например, по номеру порта - когда хочется найти конкретный порт или диапазон.

В общем, пользуемся - ports.vmware.com.

На прошедшей конференции VMworld 2019 было сделано немало интересных анонсов (о самых интересных из них мы рассказываем тут), один из них - это определенно технологическое превью Project Magna (год назад мы рассказывали о начале разработки этого продукта). Это облачное решение VMware, которое предназначено для постоянной непрерывной оптимизации инфраструктуры отказоустойчивых хранилищ VMware vSAN.

Magna представляет собой движок, который позволяет проводить самооптимизацию решения vSAN и его тюнинг, то есть автоматически тонко настраивать параметры кластеров хранилищ, наблюдая за их работой и постоянно анализируя метрики. Работать это будет как SaaS-продукт, который из облака будет осуществлять контроль над инфраструктурой vSAN:

Суть движка заключается в постоянной работе AI/ML-алгоритмов, которые непрерывно собирают и анализируют конфигурации и метрики хранилищ, после чего вносят корректировки, имея в виду главную цель - не ухудшить производительность. Как только алгоритм понимает, что в результате изменения настроек стало хуже, он откатывает действие назад, запоминает и анализирует эту ситуацию, дополняя свои внутренние алгоритмы оптимизаций.

В качестве ML-алгоритма используется так называемый Reinforcement Learning, который анализирует заданные вами KPI по производительности и сравнивает их с аналогичными конфигурациями для похожих нагрузок. Этот алгоритм постоянно проверяет тысячи различных сценариев конфигурации, чтобы найти оптимальный именно для вашей инфраструктуры. Само испытание производится методом проб и ошибок:

Также продукт vRealize Operations можно будет интегрировать с Project Magna таким образом, чтобы первый мог получить от последнего нужные конфигурации, а пользователь может поставить настройку селф-тюнинга, которая будет следовать заданной вами цели.

Цели (KPI) могу быть заданы в виде следующих вариантов:

• Read Performance - все настраивается для наименьших задержек на чтение (latency), увеличения пропускной способности (максимум для этого будет использоваться до 10% памяти хоста).
• Write Performance - конфигурация стремится уменьшить задержки и увеличить производительность на запись (пренебрегая скоростью чтения).
• Balanced - оптимизация сбалансированного режима чтения-записи, в зависимости от требований рабочей нагрузки.

Также полученные целевые KPI можно будет сравнить со средними по отрасли (эти данные будут агрегироваться от клиентов VMware). Для глубокого понимания происходящего в консоли Magna будет доступен график производительности, который в ключевых точках будет показывать, какие изменения были сделаны:

Например, на этом скриншоте мы видим, что Magna увеличила размер кэша на чтение до 50 ГБ 23 июля - и это благотворно повлияло на performance index.

Больше о решении Project Magna можно узнать из следующих сессий VMworld 2019:

• HCI1620BU – Artificial Intelligence and Machine Learning for Hyperconverged Infrastructure
• MLA2021BU – Realize your Self-Aware Hybrid Cloud with Machine Learning
• HCI1650BU – Optimize vSAN performance using vRealize Operations and Reinforcement Learning

Доступность Project Magna ожидается в следующем году.

Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.

Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.

Аппаратная спецификация кластера выглядела так:

• Platform: Supermicro SuperServer 2029UZ-TR4+
• CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
• RAM: 96GB
• Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
• Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
• RAW capacity: 9TB 
• Usable capacity: 8.38TB 
• Working set capacity: 4.08TB 
• Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
• Switch: 2x Mellanox SN2700 32 Spectrum ports 100GbE Ethernet Switch

Схема соединений тестового стенда:

Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.

Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.

С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):

Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.

Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).

Далее результаты по IOPS были следующими:

• 90% random reads и 10% writes = 5,139,741 IOPS
• 70% random reads и 30% writes = 3,434,870 IOPS

Полная табличка выглядит так:

Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.

Для 100% sequential 2M block writes получили 100.29 GBps.

Полные результаты с учетом добавления двух дисков:

А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.

Полная таблица результатов со включенным кэшированием выглядит так:

Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).

Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.

Полные результаты этого теста:

Все остальное можно посмотреть на этой странице компании StarWind, которая ведет учет результатов. Зал славы сейчас выглядит так :)

Перед предстоящей конференцией VMworld 2019, которая состоится на следующей неделе в Сан-Франциско, компания VMware сделала несколько небольших анонсов, чтобы они не потерялись на фоне больших. В частности, стала доступной для скачивания новая версия платформы VMware vSphere 6.7 Update 3, решение VMware vSAN 6.7 Update 3 и продукт VMware PKS 1.5. Ну а на днях было выпущено еще одно обновление фреймворка для управления виртуальной инфраструктурой через PowerShell - VMware PowerCLI 11.4.

Напомним, что о прошлой версии PowerCLI 11.3 мы писали в начале лета вот тут. Давайте посмотрим, что нового появилось в PowerCLI 11.4:

1. Поддержка решения Horizon View 7.9.

Модуль для работы с Horizon View (VMware.VimAutomation.HorizonView) был обновлен, чтобы поддерживать новые возможности решения VMware Horizon 7.9.

2. Обновленный модуль Storage.

В PowerCLI 11.4 был существенно доработан модуль по работе с хранилищами, чтобы поддерживать последнюю версию продукта для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Например, были обновлены командлеты Get/Set-VsanClusterConfiguration, которые теперь поддерживают функции Proactive Rebalance и vSphere Update Manager baseline preference.

Вот пример работы с этими функциями в действии (на красный текст внимание не обращайте, он говорит о том, что для работы нужен vSAN 6.7 U3):

Также появилось три новых командлета. Первый - это Add-VsanObjectToRepairQueue, он может восстанавливать объекты, которые добавляются в очередь на восстановление (ранее эта функция была частично доступна в командлете Repair-VsanObject). Второй и третий - это Get-VsanResyncingOverview и Get-VsanEnterMaintenanceMode, они работают с новыми функциями vSAN 6.7 U3.

3. Обновленный модуль HCX.

Теперь в этот модуль было добавлено целых 6 новых командлетов:

• Get-HCXAppliance - возвращает информацию о текущей версии виртуального модуля и доступных версиях.
• Его можно использовать с командлетом New-HCXAppliance - он позволяет проапгрейдить виртуальный модуль на одну из доступных версий.
• Get-HCXContainer - добавляет возможность вывести список контейнеров типа "OrgVdc".
• Get-HCXNetwork - добавляет возможность посмотреть 2 типа сетей: NsxtSegment и OrgVdcNetwork.
• New-HCXNetworkExtension - дает возможность работать с сетями типа NsxtSegment.
• Get-HCXServiceMesh - он имеет свойства, которые дают посмотреть параметры некоторых сервисов.

Пример использования командлетов Get-HCXAppliance и Get-HCXServiceMesh для просмотра нового свойства ServiceStatus:

Командлеты Get-HCXServiceMesh и Get-HCXInterconnectStatus были существенно доработаны, чтобы уметь исправлять ситуацию при различных ошибках. Также свойство DestinationNetworkValue теперь отображается корректно.

Как обычно, обновление модулей PowerCLI происходит командой:

Update-Module -Name VMware.PowerCLI

Больше информации об нововведениях PowerCLI 11.4 приведено в Change Log. Также рекомендуем почитать VMware PowerCLI 11.4.0 User’s Guide. Главный документ с примерами - VMware PowerCLI 11.4.0 Cmdlet Reference.

Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.

На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.

С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.

Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:

• Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - это фреймворк, который используется для визуализации метрик из базы.

После развертывания администратору лишь нужно указать простые настройки и подключить коллектор к одному или нескольким целевым кластерам и стартовать сервис. После этого данные будут собираться на периодической основе и могут быть визуализованы в любой момент.

В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11  (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).

Скачать vSAN Performance Monitor можно по этой ссылке.

На этой неделе, перед предстоящей конференцией VMworld 2019, компания VMware сделала пару интересных анонсов, а именно: было объявлено о новой версии платформы VMware vSphere 6.7 Update 3 и обновлении платформы создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3.

Одновременно с этим было рассказано еще об одном обновлении решения для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service). Новый релиз построен на базе ПО Kubernetes 1.14, предназначенного для развертывания и обслуживания контейнерных сред. Напомним, что ранее мы писали о возможностях PKS версии 1.3 для облака Microsoft Azure.

Давайте посмотрим, что нового появилось в PKS 1.5:

1. Поддержка Windows-сред для контейнеров.

Пока данная возможность доступна в бета-режиме. Таким образом, теперь на платформе PKS можно одновременно управлять работой контейнеров на базе Linux и Windows. Это позволит разработчикам использовать единый стек средств разработки и фреймворки, а администраторам единые утилиты для управления контейнерами.

Более подробно о бета-программе по работе с Windows-контейнерами на платформе Kubernetes под управлением PKS можно почитать вот тут.

2. Увеличение гибкости, безопасности и прозрачности для операций с кластерами.

Тут появилось 3 значимых нововведения:

• Появились новые функции по управлению кластерами Kubernetes - поддержка апгрейда отдельных кластеров, дополнительные параметры конфигурации балансировщика, а также поддержка аутентификации и авторизации на базе SAML.
• Поддержка приоритизации правил фаервола с помощью секций на уровне VMware NSX-T Distributed Firewall.
• Улучшилась обзорность кластеров - появились новые метрики, было добавлено больше информации о статусе и здоровье кластеров, разработчикам была предоставлена большая видимость в рамках пространств имен.

3. Графический интерфейс VMware Enterprise PKS Management Console.

Теперь у решения есть обновленная консоль (пока в бета-режиме), которая предоставляет интуитивно понятный интерфейс при управлении кластерами Kubernetes и их компонентами:

Предыдущая версия решения позволяла выполнять функции развертывания новых кластеров, теперь также доступны и функции апгрейда и накатывания патчей. Кроме того, был упрощен онбординг пользователей - теперь можно добавить их в специальном разделе, и они сразу же получают доступ в соответствии с ролью:

4. Прочие возможности.

Новый PKS 1.5 даст администраторам и некоторые другие новые возможности, такие как постоянный IP балансировщика (это позволит использовать человекопонятные URL), а также поддержку нового релиза Harbor 1.8, где есть новые функции автоматизации интеграций, безопасности, мониторинга и поддержки репликации между реестрами.

Также о новых возможностях платформы VMware PKS 1.5 написано в блоге Pivotal. Больше информации о самом продукте представлено на его официальной странице.

Вчера мы писали об очередной новинке на VMware Labs, мобильном клиенте vSphere Mobile Client для iOS и Android, а сегодня расскажем еще об одной утилите - Virtual Machine Compute Optimizer. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

Для этого в отчете есть колонка VMCPUsOptimized, которая принимает значения Yes или No.

Далее также идут колонки, где показаны оптимальные количества сокетов и ядер для виртуальных машин, которые было бы неплохо сделать для текущей конфигурации (OptimalSockets и OptimalCores). Текущая конфигурация также представлена в колонках VMNumSockets и VMCoresPerSocket.

Назначения колонок представлены на картинке ниже:

Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри. Для такой задачи нужно средство для сайзинга посерьезнее - например, VMware vRealize Operations Manager.

Скрипт Virtual Machine Compute Optimizer можно запускать как минимум под аккаунтом с правами на чтение инфраструктуры vCenter. Скачать его по этой ссылке.

Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:

Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).

Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.

Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:

Командлет может делать следующее:

• Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
• Ресканирует кластер, чтобы убедиться, что PE виден хостам.
• Монтирует VVol в кластере.
• Возвращает датастор хранилищу.

Пример 1 - имеется прямой доступ к массиву

Соединяемся с vCenter и создаем соединение с FlashArray:

connect-viserver -Server <vCenter FQDN>
$flasharray = new-pfaConnection -endpoint <FlashArray FQDN> -credentials (get-credential) -ignoreCertificateError -nonDefaultArray

В интерфейсе vSphere Client датастор VVol еще не будет смонтирован:

Со стороны Pure Storage protocol endpoint также не подключен:

Запускаем Mount-PfaVvolDatastore:

Mount-PfaVvolDatastore -flasharray $flasharray -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

После этого PE будет подключен к Pure Storage:

А датастор VVol будет смонтирован к кластеру:

Пример 2 - нет доступа к массиву

Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:

Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:

Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:

$vasaArrays = Get-VasaStorageArray
Mount-PfaVvolDatastore -vasaArray $vasaArrays[<desired index>] -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

Если обобщить, то процесс монтирования датастора VVol с самого начала выглядит так:

• Установка модуля PowerShell
• Соединение с массивом
• Соединение с vCenter
• Создание хостовой группы (в случае с iSCSI нужно еще настроить iSCSI-таргеты)
• Зарегистрировать VASA-провайдер
• Смонтировать датастор VVol

Полный сценарий PowerShell приведен ниже:

install-module PureStorage.FlashArray.VMware

$flasharray = new-pfaConnection -endpoint flasharray-m50-1 -credentials (get-credential) -ignoreCertificateError -nonDefaultArray
connect-viserver -Server vcenter-02

$cluster = get-cluster Embarcadaro

New-PfaHostGroupfromVcCluster -cluster $cluster -iscsi -flasharray $flasharray

New-PfaVasaProvider -flasharray $flasharray -credentials (get-credential)

Mount-PfaVvolDatastore -flasharray $flasharray -cluster $cluster -datastoreName m50-VVolDS

А так в консоли vSphere Client:

Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.

Если еще в Update 1 при установке нового плагина или обновлении старого, в случае неудачи процесс просто завершался, и приходилось смотреть в файл журнала, то теперь для этого есть графическое представление с выводом информации о возникших проблемах (например, несовместимость с новой версией платформы).

В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.

Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):

В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:

• Панель Recent Tasks в нижней части клиента
• Консоль в разделе задач (Task Console)
• Просмотр представления Tasks для выбранного объекта vCenter Server

Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.

Как происходит работа с плагинами

При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.

Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.

Ошибки плагинов при развертывании теперь детально описаны в консоли:

Также иногда к ошибке прилагается лог развертывания, например, в случае, когда их вызвало стороннее программное обеспечение, отдающее некоторый лог ошибки.

В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.

Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.

В этом случае vSphere Client обрабатывает плагины двумя способами:

• Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
• Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.

Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:

In progress

Плагин находится в стадии развертывания.

Deployed

Плагин установлен и доступен для использования через интерфейс vSphere Client.

Failed

Показывается при невозможности скачать или установить плагин:

• Download error
  • Установка из незащищенного места - используется http вместо https.
  • Невозможно получить URL плагина.
  • vSphere Client не авторизован для скачивания плагина.
• Packaging error
  • Поврежден zip-пакет плагина.
  • Отсутствует файл манифеста.
  • Отсутствует папка plugins.
  • Отсутствуют необходимые бандлы в плагине.
• Deployment error
  • Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
  • Собственная ошибка плагина (Runtime plug-in error).

Показывается когда плагин не поддерживается для данной версии vSphere Client. Возможные причины:

• Плагин добавлен в черный список администратором.
• В плагине прописано, что он поддерживает только конкретные версии vSphere Client (и вашей в списке нет).
• Это плагин на базе флэш-интерфейса под старый клиент vSphere Web Client.

Дункан написал полезный пост о том, влияет ли установка лимитов по вводу-выводу в кластере VMware vSAN (I/O Limit) на производительность операций ресинхронизации кластера и перемещение машин между хранилищами Storage vMotion (SVMotion).

Вопрос этот важен, так как многие пользуются лимитами для виртуальных машин на уровне хранилищ vSAN, но не хотят, чтобы в случае сбоя ресинхронизация кластера или перемещение машин происходили с ограничениями, которые могут увеличить время восстановления в разы.

Ответ тут прост - нет, не влияет. Лимиты устанавливаются на уровне гостевой системы для VMDK-дисков виртуальных машин и сопутствующих объектов (например, снапшоты, своп и т.п.), поэтому операции, которые проводятся извне со стороны платформы, в этом не участвуют.

Таким образом, лимиты для виртуальных машин можно ставить без ограничений и не заботиться о том, что это повлияет на время восстановление кластера и отдельных ВМ в случае сбоя. Операции SVMotion также затронуты не будут.

Июнь оказался весьма богат на новые релизы на сайте проекта VMware Labs - недавно мы писали про обновление Horizon DaaS Migration Tool 2.1 для миграции облака DaaS, новое средство Flowgate для агрегации метрик, обновления HCIBench и USB Network Native Driver for ESXi.

Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.

Основная фича утилиты - возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как размер IO и паттерн нагрузки, пакетирование (объем исходящих операций ввода-вывода), временные промежутки между пакетами, микс трафика чтения/записи, буфферизованные или прямые операции ввода-вывода и многое другое.

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

1. Выравнивание доступа к памяти по 4 КБ (страница памяти).

2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).

Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.

Довольно давно VMware не обновляла свой универсальный фреймворк для управления виртуальной инфраструктурой, но вот на днях вышел VMware PowerCLI 11.3. Напомним, что прошлая версия пакета VMware PowerCLI 11.2 вышла в марте этого года.

Давайте посмотрим, что нового появилось в PowerCLI 11.3:

1. Добавлено 22 новых командлета для управления компонентами HCX и SPBM (политики хранилищ).

Их поддержка уже была в версии 11.2, но теперь она расширилась. Для HCX теперь доступны следующие командлеты:

• Get/New/Remove/Set-HCXComputeProfile
• Get-HCXInventoryCompute
• Get-HCXInventoryDatastore
• Get-HCXInventoryDVS
• Get-HCXInventoryNetwork
• Get-HCXNetworkBacking
• Get/New/Remove/Set-HCXNetworkProfile
• Get/New/Remove/Set-HCXServiceMesh
• Get-HCXStorageProfile
• New-HCXComputeProfileDVS
• New-HCXComputeProfileNetwork
• New-HCXServiceMeshDVS

В плане поддержки SPBM, появился новый командлет Get-SpbmView, который предоставляет прямой доступ к API механизма управления политиками хранилищ. В примере ниже выведен список доступных сервисов и взаимодействие с сервисом Replication Manager для получения набора доступных методов:

Также теперь командлеты Get/Set-SpbmEntityConfiguration могут просматривать или изменять политики хранилищ SPBM для датасторов. Вот пример работ командлета для вывода параметров политики датастора:

2. Поддержка vSphere 6.7 Update 2 в модуле VMware.VIM.

Теперь последняя версия платформы vSphere полностью поддерживается для управления через этот модуль.

3. Поддержка opaque networks в командлете Get-VirtualNetwork.

Эти сети появляются как результат работы с логическими коммутаторами в решении NSX-T. В версии PowerCLI 11.2 управление такими сетями было доступно только через прямой API, а сейчас можно управлять ими с помощью высокоуровневого командлета:

Для получения дополнительной информации о таких сетях обратитесь к статье Configuring VMs with Opaque Networks.

4. Добавлена возможность создания дополнительных типов сетевых адаптеров.

Здесь были добавлены адаптеры SriovEthernetCard и Vmxnet3Vrdma, а также появились параметры PhysicalFunction и DeviceProtocol.

5. Поддержка высокоуровнего преобразования мгновенных клонов (instant clones) в обычные ВМ.

Начиная с vSphere 6.7, мгновенные клоны (instant clones) стали доступны для пользователей в производственной среде, но управлять ими можно было только через API. Теперь же с помощью PowerCLI 11.3 можно использовать командлет Set-VM совместно с параметром PromoteDisks, что даст возможность преобразовать машину instant clone в самостоятельную ВМ, которая больше не зависит от родительской. 

6. Обновлена обработка статусов кластера для свойства SpbmEnabled.

Теперь для датастора в кластере не показывается статус SpbmEnabled, так как он всегда включен и не может быть отключен пользователем.

7. Обновленная обработка пакетного режима привязки тэгов.

Теперь привязка тэгов vSphere tags с помощью командлета New-TagAssignment идет на стороне сервера в пакетном режиме, что дает существенный прирост производительности (от 12 до 18 раз):

О производительности этого процесса есть также интересная статья "Writing Performant Tagging Code".

Для получения более полной информации о нововведениях обратитесь к документу VMware PowerCLI Change Log. О самих возможностях фреймворка прекрасно рассказано в документе VMware PowerCLI 11.3.0 User’s Guide. Ну а о том, как работает тот или иной командлет, можно узнать в VMware PowerCLI 11.3.0 Cmdlet Reference.

Как обычно, обновление на версию PowerCLI 11.3 надо делать помощью командлета Update-Module:

Коллеги из Veeam Software попросили помочь в поиске человека, который будет заниматься контент-маркетингом в сфере защиты данных и обеспечения доступности виртуальных датацентров. Надо писать тексты, хорошие заголовки и брифы, а также говорить на английском (и, желательно, испанском) языке.

Veeam представлять не требуется - это один из лидеров петербургского (а сейчас уже международного) ИТ-рынка, компания которая стоит не менее 5 миллиардов долларов. Внутри отличная корпоративная атмосфера (просто потому, что стараются брать на работу адекватных людей) и возможности релокации по всему миру (если вам такое интересно). Можно переехать в Чехию, в Америку, в Бухарест, да и вообще много куда.

Ссылка на вакансию - https://careers.veeam.ru/vacancies/it/writer-content-marketing-743999689524636

Собственно, само описание:

Writer, Content Marketing

Veeam Software is a global leader in intellectual data management based in more than 30 countries that serves 343,000+ customers all over the world.

Our clients are big and midsize business from different industries.  We help 82% Fortune 500 companies to evolve the way they manage data and to ensure it’s available across any application and across any cloud infrastructure.
We are trusted by: L’Oreal, PwC, Volvo, Gatwick, Scania and many more.

In a partnership with VMware и Microsoft we help business to improve.

• Английский

•  Create short texts, product descriptions, blog posts, white papers about Veeam solutions and data management industry in general - topics might include virtualization, data protection for both physical and virtual environments, cloud data management, server networking, data center infrastructure trends etc - with purpose of helping to drive organic and paid traffic to Veeam sites and raise awareness about Veeam solutions and thought leadership. 
• Publish content via WordPress on Veeam blogs or coordinate content publishing on 3rd party platforms.  
• Collaborate with external and internal subject matter experts (evangelists, bloggers, engineers, developers, analytics, IT administrators) on content topic development and content creation. 
• Collaborate with multiple teams across regions/departments to ensure aligned content production and promotion: product marketing, campaign management, digital advertisement, email marketing, SEO, localization, creatives, web-development etc. 
• Initiate and drive projects with creative and web-development teams to ensure effective content placement on Veeam and 3rd party web sites (mainly Veeam blog UX). 
• Use Google Analytics, MOZ and similar digital analytical tools to perform regular reporting on content activities results. 
• Maintain content publishing schedule for particular audiences/regions. 
• Work with tracking, planning and CRM systems for tasks management and analytics.

• Proven written and oral communication English and Spanish language skills, including business communications. 
• In-bound and out-bound digital marketing understanding. 
• Ability to learn quickly. 
• Strong interpersonal, writing, and verbal skills. 
• Must be able to work effectively both as a team member and independently. 
• Demonstrate ability to prioritize, multi-task, and work with minimal supervision in a team environment. 
• Strong organization skills with emphasis on being conscientious and detail-oriented. 
• Strong computer skills and proficiency in Word, Excel, Outlook and PowerPoint. 
• Technical understanding of data protection industry and virtualization principles. 
• Technical background (degree or work experience as network/support engineer or similar) and/or work experience in Digital Marketing is a strong plus. 
• Working knowledge of computer software such as VMware, Windows Server/Hyper-V or similar is a strong plus. 
• Experience in Google Analytics is a strong plus. 
• Basic understanding and/or experience of PPC, SEO, analytics and web-development is a strong plus.

• Work in a stable, dynamic company
• Modern energetic multinational working environment
• Interesting people, an excellent team of professionals
• Extensive opportunities for professional growth and career
• Flexible work schedule (work on European time)
• Employment according to the Labor Code of the Russian Federation, “white” salary
• An extended medical insurance policy
• Opportunity to join the Veeam footbal/lvolleyball team
• Partial compensation of costs on fitness
• Annual leave 28 days

Откликнуться на вакансию можно по этой ссылке.

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

Администраторы отказоустойчивых кластеров хранилищ VMware vSAN часто сталкиваются с проблемами производительности, наблюдаемыми в виртуальной среде. Как правило, о таких проблемах администратор узнает двумя путями: либо ему сообщают пользователи, либо он видит алерты, которые генерируются в консоли клиента vSphere Client при превышении определенных пороговых значений.

Так или иначе, администратор должен, прежде всего, выяснить, что проблема низкой производительности приложений проявляет себя именно на уровне гостевой системы. В этом случае VMware предлагает придерживаться следующего рабочего процесса:

Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.

Задержки измеряются в миллисекундах, и интерпретация их значений зависит от контекста - размер блока ввода-вывода, характер потока (чтение/запись, последовательное/случайное). При этом latency измеряется на некотором сегменте прохождения команд к хранилищу, на каждом из участков которого также возникают свои составляющие задержек. Анализ таких компонентов Storage stack в контексте задержек и поиск узких мест - и есть основная задача администратора, решающего проблемы низкой производительности приложений для пользователей. Многое из этого можно делать с помощью утилиты ESXTOP, о которой мы много писали.

Обратите внимание, что на иллюстрации фреймворка выше, анализ виртуальной инфраструктуры и анализ приложений и их рабочих процессов находится еще до анализа метрик. Это связано с тем, что выбор метрик, на которые стоит обратить внимание в среде VMware vSAN, зависит от характера происходящих проблем.

После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":

Тут рекомендуется делать следующее:

• Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
• Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
• Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
• Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
• Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.

То есть смысл прост - если что-то тормозит в кластере VMware vSAN, то это либо дисковая подсистема, либо сетевая инфраструктура. Ну и главное - правильно идентифицировать хост/хосты ESXi, где находятся компоненты виртуальной машины.

И еще одна важная рекомендация - при траблшутинге старайтесь не менять несколько настроек одновременно, чтобы решить проблему. Во-первых, вы не сможете понять, какая из настроек или их комбинация дала правильный эффект, а, во-вторых, вы не сразу можете обнаружить, что сделанные вами настройки может и помогли машине работать быстрее, но остальные машины этого хоста или кластера значительно просели по производительности. А вернуть все назад может быть не так уж и просто.

На сайте проекта VMware Labs появилась новая интересная штука - пакет разработки для автоматизации облачных сервисов Cloud Automation Services SDK for Python.

Данный SDK представляет собой набор классов Python, предназначенных для автоматизации различных операций на уровне компонентов Cloud Assembly, Service Broker и Code Stream API при разработке новых инструментов, дополняющих средства управления облачной средой.

Для начала работы вам понадобится:

• Cloud Automation Services for Python SDK Fling, скачанный из репозитория на GitHub
• Python версии 3 (минимально 3.6)
• Сгенерированный Cloud Services Platform API Key

Установка пакета проста:

• Клонируем гит-репозиторий командой git clone https://github.com/vmware/caspyr
• В склонированной папке устанавливаем модули командой python3 setup.py install
• Смотрим примеры использования в официальном репозитории

P.S. На момент написания этой заметки репозиторий на GitHub был еще недоступен - видимо надо немного подождать.

Вчера мы писали об ограничениях технологии Persistent Memory в vSphere 6.7, которая еще только изучается пользователями виртуальных инфраструктур на предмет эксплуатации в производственной среде. Преимущество такой памяти - это, конечно же, ее быстродействие и энергонезависимость, что позволяет применять ее в высокопроизводительных вычислениях (High Performance Computing, HPC).

Ну а пока все это изучается, сейчас самое время для проведения всякого рода тестирований.

На днях VMware выпустила документ "Persistent Memory Performance in vSphere 6.7 with Intel Optane DC persistent memory", где как раз тестируется память PMEM. Сейчас на рынке представлено всего 2 таких решения:

• NVDIMM-N от компаний DELL EMC и HPE. NVDIMM-N - это такой тип устройств DIMM, который содержит модули DRAM и NANDflash на самом DIMM. Данные перемещаются между двумя этими модулями при запуске или выключении машины, а также во время внезапной потери питания (на этот случай есть батарейки на плате). На текущий момент есть модули 16 GB NVDIMM-Ns.
• Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они измеряются наносекундами. Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM.

Для тестирования производительности такой памяти были использованы следующие конфигурации тестовой среды:

При тестировании производительности ввода-вывода были сделаны следующие заключения:

• Накладные расходы на поддержку PMEM составляют менее 4%.

• Конфигурация vPMEM-aware (когда приложение знает о vPMEM устройстве) может дать до 3x и более прироста пропускной способности в смешанном потоке чтения-записи в сравнении с традиционными устройствами vNVMe SSD (они использовались в качестве базового уровня).

• Задержки (latency) на уровне приложений для конфигураций vPMEM составили менее 1 микросекунды.

Также тестировалась производительность баз данных Oracle, и там были сделаны такие выводы:

• Улучшение на 28% в производительности приложения (количество транзакций HammerDB в минуту) с vPMEM по сравнению с vNVME SSD.

• Увеличение 1.25x DB reads, 2.24x DB writes и до 16.6x в числе записей в DB log.

• До 66 раз больше уменьшение задержек при выполнении операций в Oracle DB.

В MySQL тоже весьма существенное улучшение производительности:

Для PMEM-aware приложений тоже хорошие результаты:

Ну а остальные детали процесса проведения тестирования производительности устройств PMEM вы найдете в документе VMware.